Cream of the Crop 26

home *** CD-ROM | disk | FTP | other *** search

/ Cream of the Crop 26 / Cream of the Crop 26.iso / bbs / mxu_v152.zip / UP_DOOR.DOC < prev next >

Wrap

Text File | 1997-07-26 | 52KB | 1,008 lines

╔═══════════════════════════════════════════════════════════════════════════╗ ║ FIRST THINGS FIRST - READ THE FILE WARNING.TXT BEFORE PROCEEDING! ║ ╚═══════════════════════════════════════════════════════════════════════════╝ ┌╦══╦┐ ┌╦══╦┐ ┌╦═══╦┐ │╠══╩╗┐│╠══╩╗┐└╩═══╦┐ └╩═══╩┘└╩═══╩┘└╩═══╩┘ ┌╦ ╦┐┌═╤╦╤═┐┌═╤╦╤═┐┌╔ ┌═╤╦╤═┐┌═╤╦╤═┐┌╔═══╦┐┌╔═══╦┐┌════╦┐ │║ ║│ │║│ │║│ │║ │║│ │║│ │╬══ │╬══ ┌─╔═╝─┘ └╩═══╩┘ ╧╩╧ └═╧╩╧═┘└╩═══╩┘└═╧╩╧═┘ ╧╩╧ └╩═══╩┘└╩═══╩┘└╚════┘ ┌╦═══╦┐┌╦═══╦┐┌╔═══╦┐┌═╤╦╤═┐┌╦ ╦┐┌╦═══╦┐┌╦═══╦┐┌╔═══╦┐ └╩═══╦┐│║ ║││╬══ │║│ │║ ╦ ║│├╬═══╬┤│╠══╦╩┘│╬══ └╩═══╩┘└╩═══╩┘└╩ ╧╩╧ └╩═╩═╩┘└╩ ╩┘└╩ ╚═┘└╩═══╩┘ <tm> A Subsidary Of LA-Soft ─────────────────────────────────────────────────────────────────────────────── ▀▀▀ ▀▀▀ ▀▀▀▀▀ ▀▀ ▀▀ ▀▀▀▀ ▀▀▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀▀ ▀▀ ▀▀▀▀▀▀▀ ▀▀▀ ╔══ ╦═╗ ╔═╗ ╦═╗ ╦ ╦ ╦ ╔═╗ ╔═╗ ▀▀ ▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ║ ╦ ╠╦╝ ╠═╣ ╠═╝ ╠═╣ ║ ║ ╚═╗ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ╚═╝ ╩╚═ ╩ ╩ ╩ ╩ ╩ ╩ ╚═╝ ╚═╝ ─────────────────────────────────────────────────────────────────────────────── The Universal Multimedia Interface For BBS Software Copyright 1995-Current * Larry L. Athey * BBS Utiliteez Software ─────────────────────────────────────────────────────────────────────────────── Information Regarding MAX Graphics: ─────────────────────────────────── Notice is hereby given that the MAXscript/MAXcontrol/MAXcolor language, and MAXterm are products of BBS Utiliteez Software and are protected by US copyrights listed with the US Library Of Congress (1996).... No changes, additions, subtractions, or other modifications shall be made to MAXscript/MAXcontrol/MAXcolor language or the MAX Graphics development kit without express written permission from Larry L. Athey, BBS Utiliteez Software, Alliance, Nebraska, USA.... The MAXscript/MAXcontrol/MAXcolor language may be used in any BBS or Door software 100% royalty free. You are also allowed to implement full local graphics viewing in any BBS or Door software 100% royalty free. However, any program that uses the MAXscript/MAXcontrol/MAXcolor language *MUST* bear the MAX Graphics/BBS Utiliteez Software copyright notice.... Example: MAX Graphics and the MAXscript/MAXcontrol/MAXcolor language is (C) 1995-Current * Larry L. Athey * BBS Utiliteez Software ─────────────────────────────────────────────────────────────────────────────── The Contributors: ───────────────── This is a list of people who contributed to the cause of beta testing the MAX Graphics related programs and the TDK door development kit. Although there were more people who applied to be beta testers, most of these beta sites never posted anything in the support echo, so I don't consider them to have made any contribution to the cause. But, these people stood by me and my efforts without a single sour word, and never threw in the towel.. Many people apply to be a beta tester for new programs and never think of the qwerks involved in testing untested software. So they quickly give up and avoid beta testing like the plague. Beta testing requires a person to do nearly as much work (if not actually more) as the programmer themself. Programs can't evolve without testers actually running the program and at least trying to make it work even with the bugs in it. True beta testers don't seem to know the meaning of the phrase "I give up", and that's what makes being a program author worth while. I couldn't give a damn if I get one more program registration in my life, so long as there are dedicated common sense thinking people like this standing by you, it's worth while! Let's here it for the people that refused to say "I give up"! Name: BBS: Phone: ─────────────────────────────────────────────────────────────────────────── Brad Larned (1:205/400) The Fresno Online BBS 209-276-3657 Sean Price (1:205/46) Sanctuary From The Law BBS 619-377-3611 Chris Martin (1:219/308) The Mars Station BBS 760-254-3012 Bob Wingender (1:284/11) The Oak Tree BBS 417-581-0868 Chet Rhodes (1:151/124) Hawkmoon's Realm 919-556-8363 Larry Thrasher (1:3612/650) The Night Thrasher BBS 904-937-9144 Thomas Wells (1:3621/1) Renegade's Hideout 615-326-5597 Timothy Barney (1:2622/3) The Gravel Pit 814-942-1552 Cliff Williams (1:112/124) The City Of Thought 904-645-8850 Jon Parise (1:2606/421) Infinite Twilight 908-637-8243 Arthur Stark (1:395/670) Top's Diamond Mine 254-542-8783 Ronald Schlegel (1:110/1065) Dynasty BBS 937-258-1030 David Raasch (1:280/285) Let It Shine Online! 816-461-2290 ─────────────────────────────────────────────────────────────────────────── NOTE: These names appear in no particular order, they are only listed here as the names appear in my MAX Graphics area message base.... ─────────────────────────────────────────────────────────────────────────────── This program was written using: ▀▀▀▀▀▀▀▀ ▀▀▀▀▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀▀ ▀▀▀▀▀ The DoorKit! ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀▀▀▀▀ ▀▀ ▀▀ The BBS Door Development Kit By The People - For The People! ─────────────────────────────────────────────────────────────────────────────── The ANSI/ASCII/RIP/MAX DoorKit v1.35 No Copyright Notices Expressed Or Implied Compiled By Larry L. Athey From Numerous Sources ─────────────────────────────────────────────────────────────────────────────── DISCLAIMER: ----------- This program's author has taken every precaution to insure that no harm or damage will occur on computer systems operating this package. Nevertheless, the author shall NOT be held liable for whatever may happen on your computer system or to any computer systems which connects to your own as a result of operating this package. The user assumes full responsibility for the correct operation of this software package, whether harm or damage results from any software error, hardware malfunction, or operator error. NO warranties are offered, expressly stated or implied, including without any limitation or restriction any warranties of operation for a particular purpose and / or merchantability. If you do not agree with this, then absolutely do NOT use this program! See the file WARNING.TXT for more information.... ─────────────────────────────────────────────────────────────────────────────── LICENSE AGREEMENT: ------------------ The door program, support files, and documentation are copyrighted products of BBS Utiliteez Software. The author reserves all rights to these products. This is protected by the United States of America (USA) and International Copyright Laws. In no way shall the components of the door software package be reproduced or modified in any form or method without prior expressly written permission from the author. Tampering with or altering the contents or integrity of the door software package is prohibited. No fee may be charged by any agency other than the author beyond the cost of distributing unregistered copies without prior expressly written permission from the author. This door is distributed as freeware, but is not public domain software. ─────────────────────────────────────────────────────────────────────────────── GUARANTEE: ---------- Ha Ha Ha Ha....Guarantee? Okay, if this program breaks, I guarantee that you get to keep both pieces....How's that? :) ─────────────────────────────────────────────────────────────────────────────── WHAT'S NEW: ----------- Added more command line parameters which will actually allow MAXupdate to run without a drop file at all. Added the /X command line parameter which will force MAXupdate to send a !|1K|*|#|#|# upon program exit which will force MAXterm to jump back to text (ANSI Emulation) mode. Now allows you to specify a singular RESOURCE.LST on the command line, thus allowing you to use MAXupdate more effectively with just one door at a time. Lower memory requirements and smaller executables. This is due to the fact that all local SVGA code was removed from the TDK door kit. Neater and more organized activity logging. MAXLIST.EXE no longer allows you to put any ICON_LIB.* icon libraries in your resource lists. No point in sending the caller 400K of icons that they already have by default anyway. All the benefits of the new features, bug fixes, and changes to TDK.... ─────────────────────────────────────────────────────────────────────────────── ╔═══════════════════════════════════════════════════════════════════════╗ ║ THE MAX GOLDEN RULE ║ ╚═══════════════════════════════════════════════════════════════════════╝ The golden rule of MAX Graphics is one that for some reason just can't be stressed enough...That ever so important rule is that you ABSOLUTELY MUST be able to call into your BBS to test and debug things as you add/change them. Too many people try to add MAX Graphics to their BBS or Doors, then get frustrated because their users keep saying "This doesn't work!", when the reason it doesn't work is because the SysOp just didn't test things.. Yes, granted that MAX Graphics will in theory drop into your BBS or Doors and replace the existing RIP interface, you have to keep in mind that you are dealing with a completely different animal with MAX Graphics...In RIP you usually have some amount of ANSI text displaying on the screen at all times unless you send a RIP command to disable/hide the text window...MAX Graphics is the exact opposite of this. MAX Graphics is primarily an SVGA graphical user interface with zero ANSI text displaying unless you force MAXterm to display it either with a Text_View_Port command, or by telling MAXterm to flip all the way back to ANSI emulation mode by sending !|1K|* to the comport with a screen file or a menu command...This is the biggest problem that most SysOps have...They tend to overlook this rule no matter how many times it is stressed in the MAX Graphics specifications... This is the very reason that the golden rule of MAX Graphics is that you be able to call into your BBS and test things before you EVER allow users access to the MAX side of your BBS...If you neglect to follow this simple rule and just drop a bunch of MAX screens into your BBS, and hope for the best. I can guarantee you that "The Best" is _FAR_ from what you will end up with...What you will most likely end up with is a lot of carrier drops because a user is stuck staring at a blank SVGA backdrop image while your BBS is trying to display an ANSI screen file. The user will assume either the BBS or their terminal program has locked up and reboot their machine. You will most likely end up with a few nasty comments from the user after they call back with their good old reliable ANSI terminal program... There you have it, an ever so basic rule that any SysOp should be able to remember. If you don't have a second computer, just throw an old 2400 BPS modem in your existing machine and install some kind of a multi-tasker. I can guarantee that if you just take the time to test & debug things first then MAX Graphics WILL work for you and your users... ─────────────────────────────────────────────────────────────────────────────── DESCRIPTION: ------------ This program is a Multi-BBS compatible door that allows you to update your caller's MAXterm terminal program and their resource files while online. This program can be run as a basic BBS door, or it can also be run between your BBS and front end mailer. It is suggested that you run this program in a PRELOG.BAT (or comparable batch file) in your BBS, or in between your BBS and front end mailer. Since you have implemented MAX Graphics in your BBS, you most likely don't want people calling your system using RIPterm. So if you run this program in "Front End Mode" and configure it accordingly, you can block out RIPterm callers from your BBS all together. Before this program will drop carrier on the RIPterm caller, it will give them the option to download MAXterm before dropping them. You can also configure the program to exit normally and not hang up on RIPterm callers. This program also has pre-defined DOS errorlevels programmed into it that it will exit with depending on the terminal emulation detected. This is a handy feature if you are running the program in front of your BBS. This will allow you to detect whether the remote is using RIPterm or MAXterm, and then allow you to do pre-logon screen file copying. No external protocol driver units are needed for this program. MAXupdate has built in Zmodem, Ymodem, Ymodem-G, Xmodem and Xmodem-1K protocols. NOTE: This door requires you to have the latest version of the MAXterm archive and its SETUP.EXE & MXT.RES stored someplace on your hard drive in order to update the remote's terminal program. ─────────────────────────────────────────────────────────────────────────────── WHAT EXACTLY ARE "RESOURCES": ----------------------------- When the term "Resources" is used in MAX Graphics, this means font files, sound files, image files, icon library files, MAXecutables, mouse cursors, and remote stored screen files. The MAX screen files used by your BBS are NOT what is referred to as a "Resource". Resources are basically any file that a MAX screen file uses that your BBS isn't capable of sending on the fly.... If you use any sound files in a screen file, the sound file must already exist on the remote system before they will hear it. So you must get the file from your system to their system BEFORE the BBS sends the screen to them. The same rule applies to any other resource file, it must already exist on the user's system before the user can play/display/process it. That's what this program is for, this program sends the resources to a user before they log on to your BBS and basically maintains their .PKG file for your BBS and to make sure your users always have the most up to date version of MAXterm. ─────────────────────────────────────────────────────────────────────────────── ONE QUICK NOTE BEFORE WE START: ------------------------------- I'm going to apologize ahead of time in case any part of this documentation seems kind of vague. I'm a programmer, not a teacher, so all I can do is my best. Plus, it appears that there is a world wide campaign to abolish the reading of any and all documentation, so I really don't spend a whole hell of a lot of time writing any documentation any more. If for some reason you can't understand what a certain feature does by reading this document, all I can suggest is that you tinker around with that feature for a while until you understand what it's actually doing. Hands on experience is always the best teacher and most effective way of learning something new.... ─────────────────────────────────────────────────────────────────────────────── REQUIREMENTS: ------------- At this point in time the only requirement is that you have a computer. :) You may or may not have to make modifications to other BBS configuration files or your computer start up files. Chances are that you won't.... ─────────────────────────────────────────────────────────────────────────────── SPECIAL CONSIDERATIONS: ----------------------- Below is a list of special considerations to keep in mind before you install this program. By following these considerations, you will save yourself and your users a lot of headaches in the long run.... The main thing to remember about MAXupdate is that it is "Timing Dependent", and if there is anything in your system interfering with the program timing, it's not going to work correctly.... 1. Disk compression is the worst thing you can do to your computer, this will easily cost you 70% of your computer's overall performance. Yes I know, it appears to provide you with twice the disk space. But the thing that most people don't know is that you can't compress a file twice. If you store a 100K ZIP file on a compressed drive, you'll see that you actually lose 250 to 300K of disk space. The same thing happens when you use programs where the executables are compressed (such as this program). The only place that disk compression works is with uncompressed files. Disk compression also slows down your computer and chews up conventional memory in a nasty way. Every time your computer accesses a compressed file it has to decompress it into memory or to the host drive. If any changes are made to the file, it has to be compressed again before it is saved. So you might as well look at disk compression just like throwing a TSR into your system that tells your computer it has to run PKZIP and PKUNZIP every time it accesses a file. This constant decompress/read/compress/save routine interferes with this program severely because it is timing dependent. Since MAX Graphics uses non-error-correcting text based transfer routines, disk compression will cause this program to perform erratically, or prevent it from working at all depending on the system. If you use any disk compression, then it is in your better interests not to bother installing this program until you have removed the disk compression. MAXupdate is only tuned to work with as slow as a 2400 baud modem, and when your computer is contantly doing that decompress/read/compress/save routine, the timing routines in this program simply will not work correctly. 2. When running this program under a multi-tasker, you must be sure that the DOS session has enough priority that another program running in another session isn't interfering with the timing routines. If you have a program running in another session that is hogging the CPU, it _could_ cause the results from a MAXterm query to get botched. If this happens, your users will usually start complaining because MAXupdate is always forcing them to download the same resources on every call. This will usually weed out your long distance callers if your system is doing this. :) 3. Be sure that you know your modem/fossil driver input and output buffer sizes in advance. For error free communications, you must configure the control files (ie: NODE###.CTL) correctly, and this is the main thing a lot of people overlook or set incorrectly. Setting these incorrectly is like trying to join two different sizes of pipe, you can't do it without a causing a leak. So be sure these settings are correct!!! 4. This program requires you to be able to pass the caller's actual baud rate on the command line. The port locked speed is obtained from your control files. The /S parameter is used to tell the program what speed the caller is actually connected at so the protocols can work correctly. Passing the locked port speed on the command line will guarantee you a bunch of errors in resource updates. 5. Any time you update this program, or update your system resources, you absolutely MUST run the MAXLIST.EXE utility to create new RESOURCE.LST files. If you neglect to do this, your updates are never going to work or your users will be complaining about MAXupdate forcing them to down- load the same resources all the time. 6. If you do happen to encounter callers telling you that MAXupdate forces them to contantly download the same resources over and over, you will need to see what their terminal is sending back for a resource list and compare it against your resource list(s). When MAXupdate queries MAXterm for a resource list, it will create a file in the program home directory named RES.### where the ### is the current node number. While the caller is online, you will need to either drop to DOS, or open up another DOS session under your multi-tasker and copy this file to a safe place so it can be viewed later. This is because MAXupdate cleans up after itself at exit time and that file will be deleted. After the caller logs off, look at this file in a text editor and compare the file names and their CRC32 values against your resources list(s). If the file is neatly formatted (ie: {File Name} {one space} {CRC32 Value}) and the CRC32 values are not correct, then you need to run MAXLIST.EXE again to create a RESOURCE.LST with the correct values. If the file is improperly formatted, with just partial file names or CRC32 values, then your control file settings are incorrect, or there is a bug in your Fossil/DigiBoard driver program.... ─────────────────────────────────────────────────────────────────────────────── INSTALLATION: ------------- 1. Create a directory for the door (example: "C:\DOORS\UP_DOOR"). 2. Copy all the contents of this archive into that directory. 3. Run the door MAKECTL.EXE configuration program and edit the file UP_DOOR.CFG to your preference. The UP_DOOR.CFG file is commented to explain what each line of the configuation file is for. You will also need to edit the DIR.LST file. See the section below on that file to understand its function and how to edit it. 4. To insure proper multi-node use in a DOS based multi-tasking environment, SHARE.EXE must be installed prior to the door, and prior to the OS. 5. In order to run the door program online, the following parameters may be used. For a list of all available command line parameters, simply execute the program with no parameters.... DropFile Specifiers: -------------------- "/D={Node Work Path}\DOOR.SYS" - This tells the program to use the DOOR.SYS drop file and the {Node Work Path} points to the proper directory where the drop file is to be created or found. "/R={Node Work Path}\DORINFO#.DEF" - This tells the program to use the DORINFO#.DEF drop file and the {Node Work Path} points to the proper directory where the drop file is to be created or found. Optional Parameters: -------------------- "/S##### (Where ##### is the user's actual baud rate) - This specifies the online caller's actual baud rate. You use this parameter to force a new baud rate if you are running the door with the DOOR.SYS drop file and would like to force the door to use the actual baud rate rather than the locked port speed. This is needed for the file transfer protocols to work correctly. "/N###" (Where ### is 1..?) - This specifies the current node number and tells the door which NODE###.CTL file to use. "/L" - This tells the door to load up in LOCAL mode. "/O" - This tells the door to load up in ONLINE mode. This is useful if you are running the door online without a drop file. Such is the case if you wanted to run the door between your BBS and a front end mailer or a waiting for caller program where no drop files are created in advance. "/X" - This tells the door to send a !|1K|*|#|#|# at exit time to either clear the remote screen in RIPterm or to flip MAXterm back to text mode. "/U#####" (Where ##### is the user's actual BBS record number) - This is used in the event the door needs to know the user's actual record number when it is not contained in the drop file, or if no drop file is in use. "/A#####" (Where ##### is the user's actual BBS access level) - This is used in the event the door needs to know the user's actual access level when it is not contained in the drop file, or if no drop file is in use. "/T#####" (Where ##### is the user's remaining time in minutes) - This is used in the event the door needs to know the user's actual remaining online time when it is not contained in the drop file, or if no drop file is in use. "/E#####" (Where ##### is the number of minutes until your next event) This is used in the event the door needs to know when the next event in your BBS is to take place when it is not contained in the drop file, or if no drop file is in use. "/Z[FirstName_LastName]" - This is used in the event that you have to force the user's name and alias in the door. If there is a first name and last name, they must be separated by an underscore, not a space.. ─────────────────────────────────────────────────────────────────────────────── THE UP_DOOR.CFG FILE: --------------------- 5 2.02 C:\FILES\MXT_B202.EXE C:\MAXTERM\SETUP.EXE C:\MAXTERM\MXT.RES C:\MX\LOGS\ NODE{NODE}.LOG YES ---------------------------------------------------------------------------- Definition of the UP_DOOR.EXE configuration file: ---------------------------------------------------------------------------- Line #1: How many seconds to wait for possible slowpoke remote machines. This may be required if you have a number of people calling your system with slowpoke 386/SX machines. This tells the door to sit and wait for "X" amount of seconds for their machine to kill all active windows before starting up the door. Line #2: The version of MAXscript/MAXcontrol/MAXcolor your system supports. The MAXTERM.DOC file in the MAXterm archive will say at the top of it which version it supports. Line #3: The full path and file name of your complete MAXterm archive. Line #4: The full path and file name of your MAXterm setup program. Line #5: The full path and file name of your main MAXterm installation resource file. This file and the one defined in the above are found inside of the actual MAXterm distribution archive. You will need to extract these files from the archive and put them in a directory where MAXupdate can find them. Line #6: The full path to your BBS log files. Line #7: The name of the log file to write to. The {NODE} variable will be translated to the correct node number which will allow you to run this door effectively with multi-node systems. Line #8: Set this to YES or NO to tell the program whether or not to drop carrier on RIPterm callers. If you are running this program in front of your BBS and want to block out all RIPterm callers, then set this to YES. Otherwise, set it to NO so this program doesn't constantly hang up on RIPterm callers. ─────────────────────────────────────────────────────────────────────────────── THE CONTROL FILE EDITOR: ------------------------ ┌─────────────────────────────────────────────────────────────────────┐ │ Editing Control File For Node #1 │ ├─────────────────────────────────────────────────────────────────────┤ │ SysOp First Name:[Your First Name_____] │ │ SysOp Last Name:[Your Last Name______] │ │ Name Of This BBS:[Your BBS Name___________________________] │ │ SysOp Security:[500__] │ │ Serial Number:[__________] │ │ BBS Home Path:[C:\MX\______] │ │─────────────────────────────────────────────────────────────────────│ │ Using Fossil:[Y] Input Buffer Size:[4096] │ │ Locked Port Rate:[38400_] Output Buffer Size:[4096] │ │ Digi Over Ride:[N] Non-Standard Port:[N] Save ▄ │ │ Comm Data Bits:[8] Comport Number:[1_] ▀▀▀▀▀▀ │ │ Comm Parity:[N] Port IRQ Number:[4_] Quit ▄ │ │ Comm Stop Bits:[1] Port Hex Address:[03F8] ▀▀▀▀▀▀ │ └─────────────────────────────────────────────────────────────────────┘ SysOp First Name: Self Explanatory SysOp Last Name: " " Name Of This BBS: " " SysOp Security: Set this to the same numeric value as the sysop security level on your BBS. Serial Number: Ignore this field....This is a freeware program, so you will never be issued a serial number. BBS Home Path: Enter the path to your BBS home directory here. This has nothing to do with drop files, the path to your drop files is passed on the command line. this is used so this program can locate your BBS system data files. Using Fossil: Are you using a fossil driver? [Y/N] Locked Port Rate: Enter the speed here in which your comport is locked at. Digi Over Ride: Do you want this program to use DigiBoard over ride comm routines? [Y/N] Comm Data Bits: Set to the same as your BBS's Data Bits setting. Comm Parity: Set to the same as your BBS's Parity setting. N=None, O=Odd, E=Even Comm Stop Bits: Set to the same as your BBS's Stop Bits setting. Input Buffer Size: Set this to the same as your BBS or fossil driver. Output Buffer Size: Set this to the same as your BBS or fossil driver. Non-Standard Port: Are you using a non-standard IRQ setting? [Y/N] Comport Number: The comport number for this node (If Non-Standard). Port IRQ Number: The IRQ number for this node (If Non-Standard). Port Hex Address: This port's address in hex (If Non-Standard). ─────────────────────────────────────────────────────────────────────────────── SAMPLE BATCH FILES FOR RUNNING THE DOOR: ---------------------------------------- CD\DOORS\UP_DOOR UP_DOOR.EXE /D=C:\BBS\NODE1\DOOR.SYS CD\BBS EXIT or: CD\DOORS\UP_DOOR UP_DOOR.EXE /N2 /S14400 /R=C:\BBS\NODE2\DORINFO2.DEF CD\BBS EXIT or: CD\DOORS\UP_DOOR UP_DOOR.EXE /X /D=C:\BBS\NODE1\DOOR.SYS CD\BBS EXIT or: CD\DOORS\UP_DOOR UP_DOOR.EXE /D=C:\BBS\NODE1\DOOR.SYS /F=C:\DOORS\UP_DOOR\LORD\RESOURCE.LST CD\BBS EXIT If you want to run MAXupdate in between your BBS and mailer or WFC program and don't want to use the MAKEDROP.EXE program, MAXupdate allows you to use a combination of command line parameters to allow this. Go back up in this document and see the list of valid command line parameters.... Also, if you are running MAXupdate in front of your BBS and the BBS forces the user to input a selection before any screen files are sent, you'll want to use the /X command line parameter to force MAXterm back to text mode so the user can see the prompt the BBS is presenting. Otherwise, the user will be stuck staring at a blank SVGA backdrop with no idea what to do. One such BBS package that would need this is TriBBS if you have it configured to use more than one language....Use this feature as you see fit.... ─────────────────────────────────────────────────────────────────────────────── OTHER SYSTEM FILES: ------------------- MAXupdate makes use of three text files to handle its resource updating. Two of these files are created manually with a text editor, whereas one of them is created with the MAXLIST.EXE utility. Below is a list of the files and a brief description of their purpose: DIR.LST - This file is a list of directories on your system that hold resource files to be sent before a caller logs on. If there are any MAX compatible doors on your system that don't have built in resource updating, you'll need to list the program directory that hold that program's resources in here. This is a plain text file with each directory on one line, each directory may or may not contain a trailing backslash. This file is to be located in the MAXupdate home directory. RESOURCE.LST - For every directory listed in the DIR.LST file, there must be a RESOURCE.LST file containing the file name and CRC32 value of each resource file on each line. This file should be created by the MAXLIST.EXE utility in order to assure each file is listed with the correct CRC32 value. This file is to be located in the same directory as the resources to be sent to the remote. This is a plain text file with the file name, at least one space, and then the CRC32 value. KILL.LST - This is an optional file that you manually create which is used to delete old unneeded resources from the remote that you no longer use on your BBS. This is just a courtesy on your part. If you have sent resources to your users before that you are no longer using, simply list the file name of the resource in this file and it will be deleted from the remote hard disk automatically. No CRC32 value is needed, this file is also located in the MAXupdate home directory. To create your RESOURCE.LST file(s), you simply execute MAXLIST.EXE with the directory name on the command line. You will be prompted for a yes or no response for every file located in that directory. This tells the program whether or not you want to send this file to the remote caller as a resource file. After the program exits, add the directory name to the DIR.LST file using your text editor. That's all there is to it.... NOTE: Do *NOT* put any of the default ICON_LIB.* icon libraries in your resource lists. These are default libraries that never need to be sent to the user since MAXterm won't even begin to start without them. There's no need to make a user download over 400K of icons that they already have....Is there? :) After all these files are configured, MAXupdate will do this when you run it with a MAXterm caller online: 1. Read the NODE###.CTL and UP_DOOR.CFG files. 2. Query the remote for its system information and resource list. 3. Look for the KILL.LST file and delete any resource files from the remote system (if they exist) that appear in this file. 4. Read the DIR.LST file and search for a RESOURCE.LST file located in every directory listed in this file. 5. Check every file name and CRC32 value listed in the RESOURCE.LST file against the list of resources on the remote system. 6. Send only the resources the remote doesn't have, or send the ones the remote does have, but have a different CRC32 value. 7. Exit with the predefined MAX Graphics DOS errorlevel. If you notice the definition for the "/F=" command line parameter in the above, you can tell MAXupdate to just send the resources listed in one RESOURCE.LST file. This is especially handy if you are running any doors on your BBS where you have created MAX screen files for it and you need to get the resources just for that door to the remote. Say that you have the LORD&MAX package, you would extract the resources for that package to a directory of your choice (ie C:\DOORS\UP_DOOR\LORD). Then you would run the MAXLIST.EXE utility to create a RESOURCE.LST file. Then modify the door start up batch file so that it runs MAXupdate first. You would add something like this to your door start up batch file: CD\DOORS\UP_DOOR UP_DOOR.EXE /D=C:\BBS\NODE1\DOOR.SYS /F=C:\DOORS\UP_DOOR\LORD\RESOURCE.LST Then whenever your BBS runs the door, MAXupdate will start up first, check to see if the user needs resources, send them if needed, and then exit. If you see below, MAXupdate also exits with specific error levels depending on the terminal emulation detected. So you could actually support both MAX and RIP in a door simply by trapping the errorlevel in a batch file, then copy the needed screen files accordingly. ─────────────────────────────────────────────────────────────────────────────── PRE-DEFINED DOS ERRORLEVELS: ---------------------------- MAXupdate is programmed to exit with different DOS errorlevels depending on the terminal emulation detected, and other detected conditions. Here is a list or MAXupdate's pre-programmed DOS errorlevels: 0 - Normal Exit 1 - Comm Port Error 2 - Unable To Open Drop File 3 - Carrier Lost 4 - Time Limit Expired 5 - User Inactivity Time Out 6 - System File Missing 100 - TTY Graphics Detected / Normal Exit 101 - ANSI Graphics Detected / Normal Exit 102 - AVATAR Graphics Detected / Normal Exit 103 - RIP Graphics Detected / Normal Exit 104 - MAX Graphics Detected / Normal Exit ─────────────────────────────────────────────────────────────────────────────── RUNNING IN FRONT END MODE: -------------------------- A utility (MAKEDROP.EXE) has been included in this archive to allow you to run the door between a front end mailer and your BBS. What this utility will do is create a DORINFO1.DEF drop file for the door to read which will allow it to run online before a caller logs on to your BBS. The parameters required for MAKEDROP.EXE are shown below: MAKEDROP.EXE /N[Node #] /S[Baud Rate] /M[Minutes Left] /D=[DropFile Path] Or: MAKEDROP.EXE /N1 /S28800 /M30 /D=C:\BBS\NODE1\ After you have executed this utility and created the DORINFO1.DEF drop file where you want it, you would execute the door program like this: UP_DOOR.EXE /N1 /R=C:\BBS\NODE1\DORINFO1.DEF ─────────────────────────────────────────────────────────────────────────────── THE WFC.EXE PROGRAM: -------------------- If you do not run a front end mailer, this program also contains a waiting for caller unit. This program will answer calls to your BBS, start up the UP_DOOR.EXE program, and then run the BBS.BAT file to start up your BBS... You must create a WFC###.CFG file for every node your BBS runs. The ### is the node number. See the WFC###.CFG file definition below: THE WFC###.CFG FILE: -------------------- AT&F AT&C1&D2H0M1W2S95=2 ATA 500 2400 30 ---------------------------------------------------------------------------- Definition of the WFC.EXE configuration file: ---------------------------------------------------------------------------- Line #1: Your modem's first initialization string. AT&F is a general reset command which is compatible with all modems. Line #2: Your modem's secondary (or main) initialization string. Line #3: Your modem's answer string. ATA is a general answer string which is compatible with all modems. Do not use ATS0=1 for answering! Line #4: Your modem's command delay in milliseconds. Line #5: The minimum allowable baud rate on your system. Line #6: The maximum amount of minutes you want to allow users in UP_DOOR. THE BBS.BAT FILE: ----------------- @ECHO OFF C: CD\MX MAXMENU.EXE /N%1 /B%2 This is just a generic example. The BBS.BAT file is called with the node number as the first command line parameter, and the actual baud rate as the second command line parameter. ─────────────────────────────────────────────────────────────────────────────── OTHER GENERAL INFORMATION: -------------------------- Global System Variables Used By The Door: ----------------------------------------- {TIME} = The Current Time {DATE} = The Current Date {NODE} = The Current Node Number {BAUD} = The Current Baud Rate {MINS} = Time Left Online In Minutes {PORT} = The Current Comm Port In Use {SEC} = The User's Security Level {BBS} = Your BBS Name {USER} = User's Full Name {SYSOP} = SysOp's Full Name {UFIRST} = User's First Name {ULAST} = User's Last Name {SFIRST} = SysOp's First Name {SLAST} = SysOp's Last Name {PROG} = The Program Name and Version Number {ADDR} = The Port Address Stored In The .CTL File {IRQ} = The Port IRQ Stored In The .CTL File {SYSSEC} = SysOp Security Stored In The .CTL File {SERIAL} = The Serial Number Stored In The .CTL File {INSERT1} Through {INSERT5} = These are system variables that change from time to time through out the program. Check your screen files to see what their purpose is at the time. These variables can also be used in text files and screen files used by your program. You will also want to look at your ANSI and RIP files with a text editor to make sure that any Global System Variables you have used have not been split as this will cause them to display incorrectly. There is a neat little feature incorporated in the variables called Padding that is used to allign text on your screen, or to ensure that variables will only take up X amount of characters on the screen. Any underscores "_" in a variable are translated into spaces at run time and can be used on either side of the variable. The way to look at it is a "Pad Left" and "Pad Right" sort of feature. Let's try an experiment with the {USER} variable, we'll just use some short strings of text to demonstrate the usage of variables and padding. Let's say that the user's real name is "Jimi Hendrix". (Just because...) Actual Text: Hello {USER}, how are you today? Translates To: Hello Jimi Hendrix, how are you today? Actual Text: Hello {USER________________________}, how are you today? Translates To: Hello Jimi Hendrix , how are you today? Actual Text: Hello {________________________USER}, how are you today? Translates To: Hello Jimi Hendrix, how are you today? Now, granted that these aren't really practical examples, but it shows you how padded and non-padded variables work. Padding would be especially handy if you were creating something like a user statistics screen. You could put the padded variables on an ANSI background, and since there is padding in there, the screen will always be displayed in a uniformed fashion. As you can see in the above example, the variable {USER} is padded so there is a total of 30 spaces on the screen. If you were to chop it down to 20, even if the user's name was longer than 20 characters, only 20 characters will be displayed on the screen at once. If you have ever noticed with other programs that use variables of any kind, to make sure that your screens always display perfectly alligned is to use ANSI animation to go to a specific X/Y coordinate and then plot the variable on whatever backdrop you are using. Guess what?....ASCII callers are out of luck in this case because there is no cursor control in ACSII/TTY emulation. Inline Color Tokens: -------------------- As with Global System Variables, inline color tokens are used for coloring text files and MAX screen text. Only colors 0 though 15 have any effect on MAX screens, because colors above 15 have a blinking attribute and there is no such thing as a blinking attribute in SVGA. If you send a color above 15 to MAXterm, it will simply be subtracted by 16 to return it to its non- blinking counterpart. An inline color token would look like: {14}, {1}, {31}. All colors used by the tokens correspond to the standard ANSI color values. To color a line of text in a message bright yellow, simply enter a {14} before the text to be displayed. For more examples, take a look at your P#*.ANS prompt files. Keep in mind that there is no such thing as padding in inline color tokens. ─────────────────────────────────────────────────────────────────────────────── TROUBLESHOOTING: ---------------- 1. This door DOES NOT REQUIRE a fossil driver to run correctly. 2. If you are running a high speed modem (9600 baud or above), then I suggest you run your BBS/Mailer/Doors at a locked baud rate. On high speed error correcting modems, locking the baud rate will have a noticable increase on the speed of text that is sent. It's beyond the scope of this document to discuss configuring your BBS and mailer for a locked baud rate, you may wish to consult your BBS docs for information on that. Here are a couple things to keep in mind when setting up door with a locked baud rate: a. If you are using a fossil, then make sure to tell the fossil that the port is locked. For BNU, to lock com1: at 38,400, you would use something like "L0=38400,8N1" on BNU's command line. b. If you lock the baud for one program, it must be locked for everything. You can't lock the baud for just this door, but not your BBS/Mailer. 3. If you have any incorrect settings in your NODE###.CTL file(s), you could experience some of these situations. If you don't understand what a certain setting in the CTL file does, it is probably best to leave it alone, or call a computer professional and ask them for a definition or a place to get a reference book. a. If you have the program set to use a fossil driver or DigiBoard and neither is present, the program will not be able to send any resources to the remote. b. As in the above, if any of these settings are incorrect, you and your users will see nothing but random garbage on the screen. c. Mismatched buffer settings, locked port speeds, port addresses, IRQ settings, or comport selections will lock up the program on every attempt to run it. Be sure these settings are correct. 4. What follows is some information on possible strange situations that may occur on some systems: a. Low speed users can use the door, but high speed users get garbage. - If you are the DORINFOx.DEF drop file, then there is a chance your BBS is writing the locked port speed to the drop file rather than the actual caller baud rate. You should either change to the DOOR.SYS drop file, or use the /S parameter to pass the actual baud rate to the door. Several converter programs are readily available on most BBS systems. CallDoor is a good one if you can find it. b. The door hangs up when a user enters the door. - Sounds like the door is getting the wrong baud rate somehow. Try switching over to the DOOR.SYS drop file method if possible. - This can also be cause by using a fossil driver and locking the comport at a rate higher than 38400. If this is the case, then reduce your locked port speed and try again. c. Text and screens are getting cut off. - If you are running with a locked baud, then this could be caused by some sort of FLOW CONTROL problem. Make sure your fossil is loaded correctly and not locked faster than 38400 baud. - If you're using something other than the DOOR.SYS drop file, then I always suggest trying to use DOOR.SYS if possible. It is the most reliable method and has had the most testing. If that is not possible try DORINFOx.DEF as an alternative. d. The door locks up the BBS on every node. - This can happen with fossil driver or the internal communications routines because it uses the default comport of 1 when NONE or COM0: is found in the drop file. e. ANSI is reflected correctly on the local screen but the user is getting garbage when using DORINFOx.DEF. - Assuming the user has ANSI installed then most likely the problem is at your end. First make sure the dropfile is passing the actual baud rate INSTEAD of the locked port speed. If it is not passing correct baud rate then you may need to use DOOR.SYS instead. f. When a user enters the door or when you run it locally, the screen appears to cycle (flipping) over and over until the program shuts down with a "Runtime Error 202". - This is caused by people running hacked versions of their fossil driver. Even though most of these hacks are nothing more than a copy with a new version number, once it's tampered with, it's a defective copy. Programs to avoid are BNU 2.xx and X00 2.xx. If at all possible, get your fossil drivers author direct! ─────────────────────────────────────────────────────────────────────────────── ┌───────────────────────────────────────────────────────────────────┐ │ │ │ ┌── ┌────── ┌────── ┌────── ┌────── ┌──────── │ │ ┌── ┌── ┌── ┌── ┌── ┌── ┌── ┌── │ │ ┌── ┌──────── ┌──── ┌────── ┌── ┌── ┌──── ┌── │ │ ┌── ┌── ┌── ┌── ┌── ┌── ┌── ┌── │ │ ┌────── ┌── ┌── ┌────── ┌────── ┌── ┌── │ │ │ └───────────────────────────────────────────────────────────────────┘ Not just software....It's a computer enhancement! ┌───────────────────────────────────────────────────────────────────┐ │ Contact: 1:14/703@FidoNet Or: USA MAX Graphics HQ-BBS │ │ 411:1500/0@ivNET (308)762-2239 │ │ 121:101/2@AllianceNet FAX or Data Calls │ │ maxgfx@juno.com ANSI/ASCII/MAX (No RIP) │ └───────────────────────────────────────────────────────────────────┘ ─────────────────────────────────────────────────────────────────────────────── ╔═══════════════════════════════════════════════════════════════════════════╗ ║ You may want to freq or download the file MAXTIPS.DOC from my BBS to help ║ ║ you understand the ins and outs of MAX Graphics more clearly. There isn't ║ ║ anything complicated about adding MAX Graphics to your BBS or doors, but ║ ║ I figure any extra help and information is better than none at all. True? ║ ╚═══════════════════════════════════════════════════════════════════════════╝